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(54) Apparatus and method for music-on-hold delivery on a communications network 



(57) A system for enabling music to be provided to 
callers placed on hold in a LAN network used for voice 
communications. Bandwidth consumption is minimized 
by ensuring that music-on-hold is provided in a manner 
that enables most necessary tasks to be executed by a 
client instead of a server. The music-on-hold system 
(50) is configured to transfer a small application pro- 
gram (54) or applet having an audio file (52) and a 



media player (54), from the server to the client if neces- 
sary. Concurrently, a real time protocol (RIP) stream 
carrying music is used to provide music to the client 
from the server during the applet transfer to ensure that 
the held caller receives music at all times. The RTP 
stream is initially used to provide music to held callers. 
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Description 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

[0001] The present invention generally relates to a 
system that allows voice communications over a LAN 
network, and more particularly, to a voice communica- 
tions over LAN network which includes a low bandwidth 
consuming music-on-hold system that enables music to 
be provided to callers placed on hold on the LAN. 

2. Description of the Prior Art 

[0002] Music-on-hold is a common feature that has 
been in use for many years in private branch exchanges 
(PBX) and automatic call distribution (ACD) systems. In 
such systems, typically, a B-channel is connected from 
the music source to the callers. This enables the callers 
to listen to music while on hold and waiting, for example, 
their turn in an ACD queue for the next available call 
center agent. Recently, however, packet-based commu- 
nications networks are being used for telephony over 
local area network (ToL) systems, in other words, voice 
communications over LANs. In particular, a network 
user is able to pick up a telephone and complete a call 
to a destination user who may be connected either to 
the same network server within the network, or to a dif- 
ferent server using the public switched telephone net- 
work. This is accomplished by converting voice received 
from the telephone handset into packet data, and send- 
ing the packets over the local area network (LAN) to the 
destination user. The packet data is then converted 
back into voice at the destination to enable the user to 
listen to the voice audio on a telephone handset. 
[0003] In a conventional telephone system, if available 
connections or trunks to the ACD system run out. users 
may hear a busy signal and will not be able to establish 
a connection to the ACD. There is no degradation in per- 
formance for those existing callers who had been able 
to call into the ACD system and subsequently been put 
on hold. In contrast, in an internet protocol (IP) type sys- 
tem, an almost unlimited number of users may contact 
the ACD over a single internet pipe. As the number of 
callers increases, the pipe, or communications lines, 
becomes increasingly full and all the available band- 
width may be consumed. At that point, the network may 
crash or become unacceptably slow. In addition, the 
condition may be exacerbated in ToL systems because 
an excessive number of callers on hold may cause a 
network's available bandwidth to be flooded with pack- 
ets of music. Thus, there is a need for a bandwidth pre- 
serving music-on-hold system for use with ToL 

SUMMARY OF THE INVENTION 

[0004] Briefly, the present invention relates to a sys- 



tem that enables music to be provided to callers placed 
on hold in a LAN network used for voice communica- 
tions. Bandwidth consumption is minimized by ensuring 
that music-on-hold is provided in a manner that enables 

5 most necessary tasks to be executed by a client instead 
of a server, thereby reducing traffic over the network 
communications lines. In a first embodiment of the 
invention, when a caller is placed on hold, the music-on- 
hold system is configured to transfer a small application 

10 program or applet, having a music file and a media 
player, from the server to the client. Concurrently, a real 
time protocol (RTP) stream carrying music is used to 
provide music-on-hold to the client from the server dur- 
ing the applet transfer. This ensures that the held caller 

15 receives music at all times. The RTP stream is used in 
the above manner to provide music to held callers in all 
embodiments of the invention. In another embodiment 
of the invention, the applet includes only the media 
player which is transferred from the server to the client. 

20 The music provided by the RTP stream is saved by the 
client as an audio file on a mass storage device for later 
playback by the media player. In another embodiment of 
the invention, the media player is built into the client and 
therefore eliminates the requirement for any files to be 

25 transferred from the server to the client. Again, the 
music provided by the RTP stream is saved by the client 
on a mass storage device for playback by the media 
player. 

[0005] These and other advantages of the present 
30 invention will be readily understood with reference to the 
following specification and attached drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

35 [0006] 

FIG. 1 is a diagram of the music-on-hold system in 

a communications network. 

FIG. 2 Is a detailed diagram of the music-on-hold 

40 system. 

FIG. 3 Is a detailed diagram of an alternate embod- 
iment of the music-on-hold system. 
FIG. 4 is a flow diagram of the music-on-hold sys- 
tem in operation. 

45 FIG. 5 is a detailed diagram of the automatic call 
distribution server. 

FIG. 6 is a detailed diagram of clients in the music- 
on-hold system. 

50 DETAILED DESCRIPTION OF SPECIFIC EMBODI- 
MENTS THE INVENTION 

[0007] The present invention relates to a music-on- 
hold system that is adapted to be utilized in a ToL sys- 
55 tem. As will be discussed in more detail below, the 
music-on-hold system is adapted to be used within a 
LAN to enable preservation of bandwidth. For example, 
in instances where the load on the LAN is. or may 
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become, excessive, other users may experience mild to 
severe performance degradation. In accordance with an 
important aspect of the invention, the music-on-hold 
system is able to dynamically determine the bandwidth 
requirements for providing music to the caller. This f ea- 5 
ture enables the music-on-hold system to use only the 
necessary amount of bandwidth to provide music to 
held callers, without causing the LAN connections to 
become saturated. In accordance with another irrpor- 
tant aspect of the invention, the music-on-hold system 
preserves server resources. For example, by enabling 
music files and media player files to be executed on a 
less busy client, resources may be preserved at the 
server. A client may include an end user/caller on the 
ToL system or software present on a gateway (FIG. 1 ). 
[0008] The present invention is compatible with vari- 
ous ToL systems, such as those that comply with the 
H.323 standard (incorporated herein by reference) 
promulgated by the International Telecommunication 
Union (ITU) system, in addition to others. In addition, 
the present system may also be used for multimedia 
applications, such as video-on-hold. In general, it is to 
be understood that the present Invention applies to any 
server-client system used for transmitting audio, video 
or multimedia, including internet connections. For 
example, audio messages may be delivered by an inter- 
net world wide web site to an end user wherein real time 
audio is sent as an RTP stream and other data is down- 
loaded using remaining available bandwidth. A particu- 
lar advantage of downloading the applet 54 (Fig. 2) to 
the end user is that the erxl user may choose to go 
backwards to replay parts of the music or message 
locally. Thus, network bandwidth is not impacted. Such 
a system is preferred in situations such as computer 
based training and other technical support delivery, 
wherein the user may want to retain the previously deliv- 
ered information. 

[0009] Referring to FIG. 1 , an exemplary embodiment 
of the music-on-hold system in a ToL system in accord- 
ance with the present invention, is shown, in particular, 
a number of different devices may be connected to the 
LAN, including an ACD server 96 connected to a ToL 
gatekeeper 97. Other devices may include a gateway 
122 for connecting to the public switched telephone net- 
work (PSTN) 120 and/or to a private branch exchange 
(PBX) 124 to which telephones 126a. 126b, 128 are 
connected to enable users to contact and ACD agent. 
Agents may be connected to the LAN by way of one or 
more ACD agentyjpersonal computer (PC) clients 92. 
The agents communicate with callers using telephones 
112a. 112b connected to the ACD agent/PC clients 92. 
A router 114 may also be connected to the LAN to ena- 
ble the LAN to communicate with other LANs 116 
and/or the Internet 118. Thus, it can be seen that calls 
may originate from the PSTN or PBX via the gateway, 
from within the ToL system itself the ACD system and/or 
other LANs or the Internet. It is to be noted that although 
a variety of different devices, as discussed above, may 



be connected to the LAN. the present invention is 
described wherein a user communicates with ACD 
agents through the telephones 1 1 0a. 1 1 0b connected to 
PCs with clients 98, 108. 

[0010] Refen'ing to FIG. 5. the music-on-hold system 
50 is shown implemented, for exannple, in an ACD sys- 
tem server 96. The ACD server 96. which may be any 
known communication server, such as described in U.S. 
Patent No. 5.247.670. and hereby incorporated by refer- 
ence, includes internal standard components, such as a 
CPU 100, a memory 102. and a mass storage device 

104 for storing the music-on-hold system 50. as 
described further below. As shown in FIG. 6. the tele- 
phones 112a. 112b are each connected to the ACD 
agent/PC client 92 and are used by call center agents to 
communicate with the callers on the telephones 
110a. 110b that are connected to PC clients 98. 108 
over the ToL system. The callers may. for example, be 
customers calling in to a company's customer service 
center, wherein the company uses a ToL system for tel- 
ephone communications. Audio, in the form of voice 
conversation that is sent from the call center agents, is 
downloaded or transmitted from the server 96 to the cli- 
ent 98 in packet form and then sent on to the appropri- 
ate caller. The client 98 decodes the packet voice data 
and provides voice audio to the caller. Each of the cli- 
ents 98. 108 also include a CPU 103. a memory device 

105 and a mass storage device 107. 

[0011] Referring to FIG. 2, the music-on-hold system 
50 is shown in greater detail. As mentioned above, the 
music-on-hold system 50 is responsible for providing 
music or audio to callers that are on hold while waiting 
for a call center agent to become available. The music- 
on-hold system 50, in accordance with the present 
invention, includes a small application file, or applet 54. 
that may contain a predetermined audio file 52 having 
music or a voice message. The audio file may be in the 
form of a Windows Audio-Visual (WAV) file or any other 
standard audio file format, including a musical instru- 
ments device interface (MIDI) file. The applet 54 may 
also include a media player 53 to play the audio file 52. 
The media player 53 is also capable of playing video 
files. A timer 56 and a network resources meter 58 are 
provided to determine the average wait time for a caller 
on hold and the current throughput of the network in bits 
per second, respectively. This information may be used 
to set the mode of operation of the music-on-hold sys- 
tem 50. 

[0012] For example, referring to FIGs. 1 and 2. each 
time a caller is placed on hold at the client 98. the timer 
56 determines the length of time the caller was required 
to wait before being assisted by a call center agent. The 
wait time is stored in a register in the memory 102 on 
the server 96. As each subsequent call is serviced, the 
wait time value for each call is added to the stored time 
value and the average time is calculated by the CPU 
100. In the register in the memory 102, the newly deter- 
mined average time value replaces the previously deter- 
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mined stored time value. This process is dynamic and 
repeats each time a call is answered. This provides for 
relatively precise time measurements and the availabil- 
ity of the latest data in the register in the memory 102. 
[0013] The network resource meter 58 constantly 5 
monitors the throughput of the network to determine the 
amount of available bandwidth. This value may be 
stored in a second register in the memory 102. Band- 
width availability constantly varies depending upon the 
network traffic conditions. Thus, the bandwidth determi- io 
nation process is also dynamic to ensure that the band- 
width usage numbers are relatively precise and 
available to the system at all times as well. The CPU 
100 then determines the file size of the applet and 
stores that value in another register in the memory 102 is 
for use in later calculations, as will be described below. 
[0014] If ail call center agents are busy and the caller 
Is placed on hold, the CPU 100 determines whether 
music-on-hold is to be supplied to the client 98 solely in 
a real time protocol (RTF) stream or in parallel with the 20 
transmittal of the applet 54 from the server 96 to the cli- 
ent 98. In either case, the RTP stream is used to trans- 
mit music to the client 96 to provide music to the held 
caller. 

[001 5] The GPU 1 00 makes its determination by sub- 25 
tracting a predetermined bandwidth value of the RTP 
stream from the available bandwidth value stored in 
memory 1 02. For example, the total available bandwidth 
in the network, as stored in the memory register, may be 
thirty (30) kilobits per second (Kbps), The RTP stream 30 
bandwidth may be 8Kbps. Thus, after subtracting the 
RTP stream bandwidth from the total available band- 
width, an available throughput of 22Kbps is left. The 
available throughput is then used to determine the 
amount of time required to download the applet 54 from 35 
the server 96 to the client 98. For example, if the size of 
the applet 54 (which may include the audio file 52 and 
the media player 53) stored in a register in the memory 
102, is say 512 kilobytes (KB) in size, then downloading 
the applet 54 from the server 96 to the client 98 may 40 
take approximately three minutes. 
[0016] The CPU 100 compares the calculated down- 
load transfer time with the average wait time already 
stored in the memory register. If the wait time is less 
than the download time, then only the RTP stream is 45 
sent, since the call will most likely be answered by a call 
center agent before the applet 54 can finish download- 
ing. On the other hand, if the average wait time, for 
example, is five minutes, and the applet 54 download 
transfer time is only three minutes, then the applet 54 so 
may be sent from the server 96 to the client 98. Thus, 
bandwidth is preserved by eliminating the transmission 
of the RTP stream during the last two minutes of the 
caller's wait. The preserved bandwidth can thus be allo- 
cated to other uses, such as enabling another caller to ss 
access the ACD server 96. It should be noted that 
because many of the time values are dynamic, the 
above calculations are dynamic as well. Accordingly. 
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the CPU 100 can choose to initiate or terminate the 
applet file transfer procedure at any time. 
[001 7] In instances where the gateway 1 22 is used for 
connecting to the PSTN 120 and the PBX 124. the 
applet 54 may be downloaded to the gateway 122, to 
ensure that the ACD server 96 resources and network 
bandwidth are not used in providing music. Similarly, if 
the router 1 14 is used to connect to other LANs 1 16 or 
to the internet 118, the applet 54 is sent from the ACD 
server 96 to the external LAN user or to the internet 
user for execution. 

[0018] Referring to FIG. 3. an alternate embodiment 
of the invention is shown. In particular, the music-on- 
hold system 50 is configured such that the applet 54 
includes only the media player 53 and not a music file. 
As such, the applet 54 is much smaller in size and the 
transfer time for downloading the applet 54 from the 
server 96 to the client 98 is significantly reduced. Music, 
which is to be played by the media player 53, upon com- 
pletion of the download, is obtained from the RTP 
stream. In particular, the music that is being sent in the 
RTP stream is copied from the RTP stream and stored 
on the client mass storage device 107 (FIG. 6) on the 
PC client 98. Therefore, once the media player 53 is fin- 
ished downloading, the RTP stream may be stopped. 
This may accomplished intelligently by the ACD system. 
For example, if the call center is in the middle of a mes- 
sage, it can wait until the end of the speech to stop the 
stream. Alternatively, a message may be sent to the 
applet stating exactly where the music-on-hold file is 
stopping so that the applet can continue from where the 
RTP stream stopped. Music-on-hold or other audio is 
then provided at the client by the media player 53 play- 
ing the saved audio file. 

[0019] In another alternate embodiment of the inven- 
tion, as shown in FIG. 6, the media player 53 is built into 
the client 108 and stored on the mass storage device 
107. Accordingly, the necessity tor transferring the 
media player 53 from the server 96 to the client 108 is 
eliminated. To preserve even more bandwidth, the 
applet 54 may be configured to be only a very small file 
containing configuration information and control signals 
such that even a music file is not transferred, as 
described above. Thus, bandwidth normally required in 
transferring the media player 53 is preserved in addition 
to the bandwidth saved in not transferring the music file. 
The only bandwidth usage is by the RTP stream carry- 
ing music or audio messages from the server 96 to the 
client 108, The client 108, in order to obtain music for 
the music-on-hold system, saves the received RTP 
stream on the mass storage device 107. Once the par- 
ticular song or message provided by the RTP stream is 
complete, the client 108 sends a message to the server 
98 advising it to terminate the RTP stream. The client 98 
is then able to replay the stored audio using the built in 
media player at the client instead of the server. 
[0020] Referring to FIG. 4, a specific embodiment of 
the present invention is shown in operation. In particu- 
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lar. a caller dials the ACD system in step 200. In step 
202, the system detemnines whether the call center 
agents are busy If it is determined that the agents are 
not busy, the call is completed in step 204. However, if 
the agents are busy, the caller is placed on hold and the s 
ACD calculates the average length of time the caller 
must spend in the queue in step 206. In step 208, the 
ACD determines throughput on the network in bits per 
second. In step 210. the system begins the process of 
comparing the file size with the throughput and average io 
queue time of the call. In step 212, the ACD determines 
whether the file size divided by the available throughput 
is less than the average queue.time. If not. then in step 
214, only music-on-hold Is sent in an RTP stream to the 
caller until the call Is answered by a call agent. If how- is 
ever, it is determined that the file size divided by the 
available throughput is indeed less than the average 
queue time, then in step 216 the applet is transfen-ed 
from the server to the client The RTP stream continues 
to carry the music-on-hold during the transfer. In step 20 
218. a message is sent to the call center server to stop 
the RTP stream once the download of the applet is com- 
pleted. In step 220. music-on-hold is played at the cli- 
ent's site to the waiting callers until the call is answered 
by a call center agent or the caller hangs up. The sys- 2s 
tem exits in step 222. 

Claims 

1 . A system for providing music over a computer net- 30 
work to a user connected to a client workstation by 
way of a telephone who has been placed on hold, 
said system comprising: 

a local area network; 35 
means (53) stored on said local area network 
for playing audio; 

means (54) for transferring said playing means 
(53) from said local area network to said client 
workstation such that said playing means plays 40 
locally at said client workstation. 

2. The system of claim 1 . wherein said playing means 
(53) includes a media player program for playing 
said audio. 45 

3. The system of claim 1 , wherein said playing means 
(53) is transferred from said server to said client, for 
execution at said client workstation. 

50 

4. The call hold system of claim 2, further including 
including an audio file (52) and a media player pro- 
gram (53) for playing said audio file (52). 

5. A system for providing audio to a caller placed on 55 
hold, said system comprising: 

a server; 




a client having a mass storage device in com- 
munication with said server; 
means (96) for transmitting a stream of audio 
from said server to said client, said transmitting 
means providing real time audio to said caller 
when said caller is on hold, said audio being 
stored by said client on said mass storage 
device; and 

means (54) adapted to be downloaded to said 
client in parallel with said continuous stream for 
enabling said client to terminate said continu- 
ous stream and to play said downloaded audio 
locally from said client. 

6. The system of claim 5, wherein said enabling 
means (54) is already present on said client. 

7. A system for providing multimedia programming 
over a computer network to a user connected to a 
client workstation by way of a telephone who has 
been placed on hold, said system comprising: 

a local area network; 

means (54) stored on said local area network 
for playing multimedia: 

means (50) for transferring said playing means 
(54) from said local area network to said client 
workstation such that said program plays video 
locally at said client workstation. 

8. The system of claim 7, wherein said playing means 
(54) includes a media player program for playing 
said multimedia. 

9. The system of claim 7, wherein said playing means 
(54) is transferred from said server to said client, for 
execution at said client workstation. 

10. A system for providing multimedia programming to 
a caller placed on hold, said system comprising: 

a server; 

a client having a mass storage device in com- 
munication with said server; 
means (96) for transmitting a continuous 
stream of multimedia data from said server to 
said client, said continuous multimedia data 
stream adapted to provide real time multimedia 
to said caller when said caller is on hold, said 
multimedia data being stored by said client on 
said mass storage device; and 
means (54) stored on said server adapted to be 
downloaded to said client in parallel with said 
continuous multimedia data stream for ena- 
bling said client to terminate said continuous 
stream and to play said downloaded multime- 
dia locally from said client. 
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